Internet-orientated ad-hoc network

ABSTRACT

A hierarchical directional internet-oriented ad-hoc network, defined by a software infrastructure, is composed of fixed gateway nodes and a plurality of wireless nodes, which may be fixed or mobile, and which may act as subscribers, routers, or both. The infrastructure hierarchy is defined by the hop count of each node (distance of that node to a fixed gateway node). The software infrastructure includes two tables associated with each node in the network: the upstream routing table which provides shortest routes to fixed gateway nodes through upstream neighbors, and the downstream routing table which provides shortest routes to subscribers through downstream neighbors. These two tables are used by routing algorithms. A peer table can also be used for alternate routes. The maintenance of the aforementioned tables is performed by autonomous algorithms operating locally on each node by receiving and processing signals from their neighbors.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is a continuation application of U.S. patentapplication Ser. No. 11/014,700, filed Dec. 20, 2004, which isincorporated by reference in its entirety.

BACKGROUND

Ad-hoc networks are becoming more widely used, especially for mobilewireless devices. An attractive feature of ad-hoc networks is that theydo not require a network infrastructure of base stations/fixed gatewaynodes to enable communications between wireless nodes. Instead, thewireless nodes are capable of acting as base stations/access points thatrelay communications for other wireless nodes in the network. Thus, eachnode can, at various times, act as a source of information, a drain forinformation, and a router for information.

Traditionally, the focus of ad-hoc networks has been communicationsbetween wireless nodes on the network. More sophisticated ad-hocnetworks that provide for access to fixed, wired networks have also beenproposed. This allows wireless devices to communicate with other typesof wired networks, such as the PSTN and the Internet.

One shortcoming associated with known ad-hoc networks, including themore sophisticated ad-hoc networks discussed above, is that they aretypically oriented toward enabling communication between nodes, with thedirection of such communication being somewhat random. These networksare not as efficient as possible for other types of communication, suchas Internet-oriented communication, in which the flow of data isstrongly directional (i.e., from fixed gateway nodes downward towireless nodes and vice versa).

What is needed is a network that can efficiently handle communicationssuch as the Internet that are directionally oriented.

SUMMARY

The aforementioned issues are addressed to a great extent by an ad-hocnetwork with an internet-oriented, software-defined dynamicinfrastructure. The ad-hoc network includes at least one fixed gatewaynode and a plurality of wireless nodes. As used herein, a fixed gatewaynode means a node that is in a fixed location and that acts as agateway, or access point, between the ad-hoc network and another networksuch as the Internet. In some embodiments, all of the wireless nodes aremobile. In other embodiments, some of the wireless nodes are mobile andsome are at fixed locations, which shall be referred to herein as “homenodes.” (As used herein, the term “home node” should be understood torefer to a wireless node that is in a fixed location and should not beunderstood to be limited to a fixed wireless node installed in aresidence). At least some of the wireless nodes, and, in someembodiments, all of the wireless nodes, may perform a routing functionfor other wireless nodes. In embodiments with multiple fixed gatewaynodes, the fixed gateway nodes may be connected to the other network viaa central node or may be connected directly to the other network. In thelatter case, the fixed gateway node serves as a central node.

This ad-hoc network is hierarchical based on distances, measured in hopcounts, to fixed gateway nodes. Each of the wireless nodes in thenetwork (which may be fixed wireless nodes or mobile wireless nodes) inthe ad-hoc network has a hop count with respect to each fixed gatewaynode. Any given wireless node may have one or more neighborhood nodeswith which the wireless node can communicate directly. The neighborhoodnodes will be either upstream (i.e., closer, as measured by hop count,to the fixed gateway node), downstream (further away, as measured by hopcount, from the gateway node), or at the same distance (referred toherein as a peer node).

Each wireless node in the network also has at least one of each of fourtables that describe the node's neighborhood and that are used forrouting and other functions: 1) a downstream neighbor table, 2) adownstream routing table, 3) an upstream routing table, and 4) a peertable. The upstream routing table lists each upstream node in thewireless node's neighborhood together with a hop count to the fixedgateway node. In embodiments with multiple fixed gateway nodes, there isa plurality of upstream routing tables and each upstream routing tablepertains to a different fixed gateway node. The peer routing table listseach peer node in the node's neighborhood along with an associated hopcount to the fixed gateway node and, in embodiments with multiple fixedgateway nodes, each node has a separate peer table for each fixedgateway node. The downstream neighborhood table lists each downstreamneighbor with respect to a particular fixed gateway node (again, thereis a separate downstream neighborhood table for each fixed gateway nodein embodiments with multiple fixed gateway nodes). The downstreamrouting table lists each downstream node (including downstreamneighborhood nodes) reachable from the node together with an associatedhop count, and in embodiments with multiple fixed gateway nodes, thereis a multiplicity of downstream routing tables and each downstreamrouting table pertains to a different fixed gateway node. Theaforementioned tables define the connectivity for the network. A numberof triggers are generated during routing and at other times to cause theupdate of these tables. The tables are also audited periodically, eitheron an individual node basis or for the tables as a whole.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned advantages and features will be more readilyunderstood with reference to the following detailed description and theaccompanying drawings in which:

FIG. 1 is a schematic diagram of a network with one fixed gateway nodeaccording to a first embodiment.

FIG. 2 is a schematic diagram of a network with two fixed gateway nodesaccording to a second embodiment.

FIGS. 3 a and 3 b are conceptual schematic diagrams illustrating twosuperimposed networks that together comprise the network of FIG. 2.

FIG. 4 is a schematic diagram of a network with fixed gateway nodesrouted through a central node according to a third embodiment.

FIG. 5 is a logic diagram illustrating a packet routing process.

FIG. 6 is a flowchart illustrating in further detail the processingassociated with one of the steps of FIG. 5.

FIG. 7 is a flowchart illustrating in further detail the processingassociated with another of the steps of FIG. 5.

FIG. 8 is a flowchart illustrating the processing associated with adownstream trigger D1.

FIG. 9 is a flowchart illustrating the processing associated with adownstream trigger D2.

FIG. 10 is a flowchart illustrating the processing associated with anupstream trigger U1.

FIG. 11 is a flowchart illustrating the processing associated with atrigger T4.

FIG. 12 is a logic diagram illustrating various processing of a triggerT5 depending upon the difference in hop counts between the sending andreceiving nodes.

FIG. 13 is a flowchart illustrating in greater detail the processingassociated with one of the steps of FIG. 12.

FIG. 14 is a flowchart illustrating in greater detail the processingassociated with one of the steps of FIG. 12.

FIG. 15 is a flowchart illustrating in greater detail the processingassociated with one of the steps of FIG. 12.

FIG. 16 is a flowchart illustrating in greater detail the processingassociated with one of the steps of FIG. 12.

FIG. 17 is a flowchart illustrating in greater detail the processingassociated with one of the steps of FIG. 12.

DETAILED DESCRIPTION

In the following detailed description, a plurality of specific details,such as numbers of nodes and hops, are set forth in order to provide athorough understanding of the embodiments described herein. The detailsdiscussed in connection with the preferred embodiments should not beunderstood to limit the present invention. Furthermore, for ease ofunderstanding, certain method steps are delineated as separate steps;however, these steps should not be construed as necessarily distinct nororder dependent in their performance.

An exemplary network 100 is illustrated in FIG. 1. The network 100includes a fixed gateway node A, a plurality of mobile wireless nodes1-14, and a home wireless node 15. The fixed gateway node A is connectedto an Internet backbone and has wireless transmission and receptioncapability that allows it to act as an access point for a plurality ofwireless nodes. Mobile wireless nodes 1-14 and home wireless node 15also have wireless transmission and reception capability that allow themto communicate with other wireless nodes in the network and with thefixed gateway node (provided that the fixed gateway node is within rangeof the wireless transmission and reception system). Each of the mobilenodes 1-14 have the ability to act as routers for other wireless nodesin the network. (In alternative embodiments, only a portion of themobile nodes have this ability.) The home node 15 does not have theability to act as a router for other subscriber nodes in the embodimentof FIG. 1. Although only one home node 15 is illustrated in FIG. 1, itshould be understood that there may be a plurality of such home nodes inother embodiments and that some or all of such home nodes may have theability to act as routers. It should also be understood that, in variousembodiments, a particular wireless node, whether it be mobile or fixed,may be configured such that it only acts as a router, only act as asubscriber (i.e., a source or drain of information) or acts as both arouter and a subscriber.

As discussed above, the network 100 is an Internet-oriented network.Accordingly, each of the wireless nodes 1-15 can be classified based onthe number of hops, or hop count, measured with respect to the fixedgateway node A. Nodes 1 and 2 have a hop count of 1, nodes 3-6 have ahop count of 2, nodes 7-9 have a hop count of 3, nodes 10-13 have a hopcount of 4, and nodes 14 and 15 have a hop count of 5.

Each wireless node may have one or more other wireless nodes with whichit is directly connected. As used herein, a second node is “directlyconnected” to a first node when the first node can communicate with thesecond node using its wireless communication system without requiringany other node to relay messages between the first and second nodes. Theset of nodes that are directly connected to a node form the neighborhoodfor that node. The neighborhood for any wireless node can include nodeswith lower hop counts (upstream nodes), nodes with the same hop count(peer nodes), and nodes with lower hop counts (downstream nodes).

Each of the nodes of the network 100 have at least one neighborhoodnode. For example, the neighborhood for node 5 includes upstream nodes 1and 2, peer nodes 4 and 6, and downstream nodes 8 and 9. Every node inthe network 100 has at least one upstream node (which may be the fixedgateway node A or another wireless node), and some have a plurality ofupstream nodes. At any given time in any particular network, a wirelessnode may have zero (in which case it is isolated), one or many upstreamnodes and may have zero, one or many peer nodes and zero, one or manydownstream nodes. Each node will have downstream neighborhood tables(DNTs) and peer tables (PTs) that list each downstream and peerneighbor, respectively, along with the corresponding hop count relativeto the fixed gateway node.

Each wireless node will also have an upstream routing table (URT) whichwill include the fixed gateway node with which the URT is associated andall upstream nodes (nodes with lower hop counts) in that node'sneighborhood. The URT will also include a hop count for each of theneighboring nodes listed in the URT. Exemplary URTs for nodes 1, 5, and8 are provided in Tables 1, 2 and 3 below.

TABLE 1 URT for Node 1 Node Hop Count A 1

TABLE 2 URT for Node 5 Node Hop Count 1 1 2 1

TABLE 3 URT for Node 8 Node Hop Count 4 2 5 2

The PT for a node will have a format similar to that of the URT, butwill list peer neighbors rather than upstream neighbors. A detaileddiscussion of how the URTs and PTs are utilized for routing packets isset forth below.

Each node also has a downstream routing table, or DRT, which the nodewill utilize in order to determine how to rout packets downstream. TheDRT for a node includes each node that is reachable from a node bytraveling in a purely downstream direction regardless of the number ofhops. In other words, an other node is included in the DRT for aparticular node if and only if a path exists from the particular node tothe other node, and that path is purely downstream (i.e., eachsuccessive node on the path has a higher hop count than the previousnode). One result of the foregoing is that routing will always be donethrough the shortest path as measured by hop count. Another consequenceis that the DRT of a node with only upstream and/or peer neighbors willbe empty.

Three different types of downstream routing tables may be utilized: DRTsindexed by destination node, DRTs indexed by downstream neighbors, andDRTs double-indexed by both destination node and by downstreamneighbors. Examples of the first type of DRT for nodes 1, 2 and 5 andfixed gateway node A are presented below in tables 4-7:

TABLE 4 DRT Indexed by Destination Node for Node 1 Node Hop CountThrough Downstream Neighbors 4 1 — 5 1 — 8 2 4, 5 9 2 5 10 3 5 11 3 4, 512 3 4, 5 13 3 4, 5 14 4 4, 5

TABLE 5 DRT Indexed by Destination Node for Node 2 Node Hop CountThrough Downstream Neighbors 3 1 — 5 1 — 6 1 — 7 2 3, 6 8 2 5 9 2 5, 610 3 3, 5, 6 11 3 5 12 3 5 13 3 5, 6 14 4 3, 5, 6

TABLE 5 DRT Indexed by Destination Node for Node 5 Node Hop CountThrough Downstream Neighbors 8 1 — 9 1 — 10 2 9 11 2 8 12 2 8 13 2 8, 914 3 8, 9

TABLE 7 DRT Indexed by Destination Node for Fixed Gateway Node A NodeHop Count Through Downstream Neighbors 1 1 — 2 1 — 3 2 2 4 2 1 5 2 1, 26 2 2 7 3 2 8 3 1, 2 9 3 1, 2 10 3 1, 2 11 4 1, 2 12 4 1, 2 13 4 1, 2 145 1, 2 15 5 1, 2

Certain aspects of the DRTs listed above are worth noting. First, forall nodes in the DRT that are not directly accessible, the third columnof the DRT indicates the directly accessible neighboring nodes throughwhich such non-directly accessible nodes can be reached.

A second aspect of the DRT tables is that not all nodes with higher hopcounts that could possibly be reached from a given node are included inthe DRT. For example, the DRT for node 2 does not include an entry fornode 4 even though node 4 has a higher hop count (2, as compared to ahop count of 1 for note 2) and even though there is a path from node 2to node 4 through node 5 that does not require any upstream travel. Thereason why node 4 is not included in the DRT for node 2 is that theportion of the aforementioned path from node 5 to node 4 is not purelydownstream because both node 4 and node 5 have a hop count of 2 (i.e.,nodes 4 and 5 are peers). Similarly, node 8 is listed in the DRT fornode 2, but no path through node 6 is shown. Again, this ensures thatpackets will be routed upstream toward the fixed gateway node throughthe shortest path as measured by hop counts.

A third aspect of the DRT tables is that multiple paths are shown insome instances. For example, the DRT for node 1 shows that node 11 isreachable in three hops via either node 4 or node 5. The choice betweenpossible paths can be made by the node based on a random selection,relative loading of the multiple nodes, or any other technique.

A second type of DRT is indexed by downstream neighbors rather than bydestination node. For each downstream neighboring node, the DRT includesa list of all nodes reachable through purely downstream paths along withan associated hop count. This type of DRT is advantageous because itsconstruction is simple—the DRTs of downstream neighboring nodes aresimply concatenated. However, this type of DRT requires a search of theDRT table in order to select a shortest path for a particulardestination. Examples of this second type of DRT for nodes 2, 3 andfixed gateway node A are set forth below in Tables 8-10 below:

TABLE 8 DRT Indexed by Downstream Neighbor for Node 2 Nodes ReachableNodes Reachable Nodes Reachable Through Through Through Node 3/HC Node5/HC Node 6/HC  3/1  5/1  6/1  7/2  8/2  7/2 10/3  9/2  9/2 14/4 10/310/3 11/3 13/3 12/3 14/4 13/3 15/5 14/4 15/5

TABLE 9 DRT Indexed by Downstream Neighbor for Node 3 Nodes ReachableThrough Node 7/HC  7/1 10/2 14/3

TABLE 10 DRT Indexed by Downstream Neighbor for Fixed Gateway Node ANodes Reachable Through Node 1/HC Nodes Reachable Through Node 2/HC  1/12/1  4/2 3/2  5/2 5/2  8/3 6/2  9/3 7/3 10/4 8/3 11/4 9/3 12/4 10/4 13/4 11/4  14/5 12/4  15/5 13/4  14/5  15/5 

As alluded to above, an advantage of using DRTs indexed by downstreamneighboring nodes is that they are easily constructed and updated usinginformation from downstream nodes. Each column of the DRTs aboverepresents the downstream cluster of the corresponding downstreamneighbor. The downstream cluster for any particular node can be formedby simply forming the union of each of the columns of the DRT for thatnode, adding 1 to each of the hop counts in the union, and then addingthe particular node along with a hop count of 0. Thus, for example,downstream cluster for node 2 (DC₂) is shown below in table 11:

TABLE 11 DC_(i) 2/0 ---------/ Node 2 itself with HC = 0 3/1 / union ofcolumns of 5/1 / DRT of Node 2 with 6/1 / associated hop counts 7/2 /8/2 / 9/2 / 10/3  / 11/3  / 12/3  / 13/3  / 14/4  / 15/4  ---------/

As will be discussed in further detail below, the DC for a node is sentby that node to its upstream neighbors in a trigger message.

The third type of DRT is double indexed by both destination anddownstream neighbor. An example of this type of double-indexed DRT fornode 2 is provided in Table 12 below (where “x” signifies that a routeexists between the given node and the destination node corresponding toa row through the downstream neighbor corresponding to a column):

Destination Nodes Reachable Nodes Reachable Nodes Reachable Node ThruNode 3/HC Thru Node/5 HC Thru Node/6 HC 3 x/1 5 x/1 6 x/1 7 x/2 x/2 8x/2 9 x/2 x/2 10 x/3 x/3 x/3 11 x/3 12 x/3 13 x/3 x/3 14 x/4 x/4 x/4 15x/4 x/4

Double-indexed DRT tables have the advantages of efficiency for bothconstruction and routing. In preferred embodiments, the DRTs arerepresented as sparse matrices when used with large numbers of nodes.

In the network 100 of FIG. 1, there is only a single fixed gateway nodeA. However, it will be readily apparent that networks sometimes includemultiple fixed gateway nodes. An example of a network 200 with the samewireless nodes 1-15 and two fixed gateway nodes A and B is illustratedin FIG. 2. As illustrated in FIGS. 3( a) and 3(b), the network 200 canbe thought of as the superimposition of the two networks 300, 400, onewith fixed gateway node A and one with fixed gateway node B. Thus, themethods set forth above with respect to the network 100 of FIG. 1 can beextended to the two fixed gateway node network 200 of FIG. 2 by creatingURTs, PTs, and DRTs for each node for each of the individual networksillustrated in FIGS. 3( a) and 3(b).

Some nodes (e.g., node 1) will have only a single URT because only onefixed gateway node is upstream of that node. Other nodes (e.g., node 3)will have multiple URTs for multiple fixed gateway nodes, but one URTwill have a shorter route than the other (node 3 is one hop from fixedgateway node B but is two hops from fixed gateway node A). In this case,the URT corresponding to the shortest distance (smallest number of hops)is designated as the primary URT and the other URT is designated as thesecondary URT. The secondary URTs can be used in cases where the path tothe primary fixed gateway node associated with the primary URT isblocked. Finally, still other nodes will have multiple URTs with thesame minimum distance/hop count. In such cases, both URTs will bedesignated as primary and both will used for routing purposes. Thechoice of which of the multiple URTs to use can be based on loadbalancing, random selection, or some other process.

Maintaining multiple node associations (through primary and secondaryURTs or multiple primary URTs as well as in a single URT) is useful andimportant for three reasons: 1) as a vehicle moves, it may drop itsprincipal association with one fixed gateway node and move to a new one;2) a failure in part of the network may be recovered by using alternaterouting through alternate nodes; and 3) alternate paths may be used forload balancing purposes.

In the network 200 illustrated in FIG. 2, node 3 is only associated withfixed gateway node B and node 1 is only associated with fixed gatewaynode A. Also, node 3 is not in either the DRT or the URT for node 1, andvice-versa. One way in which to effect communications between thesenodes is via the Internet. However, in other embodiments of theinvention, the fixed gateway nodes are linked to a central node which isthen connected to the Internet. An example of such a network 400 withfixed gateway nodes A and B linked to central node 410 is illustrated inFIG. 4. In such an embodiment, the central node 410 has a downstreamrouting table for each of the fixed gateway nodes and each of thewireless nodes in the network. Exemplary DRTs are set forth in Tables 13and 14 below (although not shown below, double-indexed DRTs are alsopossible):

TABLE 13 Central Node DRT with Indexing by Downstream Neighbors ThroughDownstream Target Node Hop Count Neighbors A 1 B 1 1 2 A 2 2 A, B 3 2 B4 3 A 5 3 A, B 6 3 A, B 7 3 B 8 4 A, B 9 4 A, B 10  4 A, B 11  5 A, B12  5 A, B 13  5 A, B 14  5 A 15  6 A, B

TABLE 14 Central Node DRT with Indexing by Destination Nodes NodesReachable Through A/HC Nodes Reachable Through B/HC A/1 B/1 1/2 2/2 2/23/2 4/3 5/3 5/3 6/3 6/3 7/3 8/4 8/4 9/4 9/4 11/5  10/4  12/5  11/5 13/5  12/5  15/6  13/5  14/5  15/6 

A node associated with multiple fixed gateway nodes A, B, C, etc. willhave one set of the URT, PT, DNT and DRT for each of the correspondingfixed gateway nodes A, B, C, etc., respectively.

The routing algorithm from the internet to a subscriber (downstreamrouting) uses the DRTs to select one of several possible shortest routesto the subscriber. The routing algorithm from a subscriber to theInternet uses the URTs to select one of several possible shortest routesto the Internet. Subscriber to subscriber routing will use both DRTs andURTs. Alternate routing through upstream and downstream neighbors may bechosen in the case of routing failure, for “handover” from one fixedgateway node to another, or for load balancing.

The creation of the routing tables, and hence the network, will now bediscussed. The process begins by constructing upstream routing tables.Initially, all wireless nodes have an infinite hop count, no neighbors,and empty URTs, and fixed gateway nodes have a zero hop count, nodownstream neighbors and empty DRTs. As wireless nodes detect othernodes (which may be accomplished through periodic broadcast pollingmessages), the other wireless nodes are registered into that node's PTwith an equal infinite hop count. As the fixed gateway nodes detectdirectly connected wireless nodes, those wireless nodes are assigned ahop count of 1. The wireless nodes detected by the fixed gateway nodethen propagate the information concerning the fixed gateway node toother nodes they have previously detected as peers and to new wirelessnodes detected thereafter (the techniques by which this information ispropagated will be discussed in further detail below). In this manner,the upstream hierarchy is established.

The DRT construction process can be triggered in either of two ways: 1)when the process of URT construction reaches nodes without downstreamneighbors; or 2) when a node modifies its URT. In addition, eventsencountered during packet routing operations will also triggermodifications to the routing tables as discussed in further detailbelow.

Use of the routing tables to perform routing operations will now bediscussed with reference to the logic diagram 500 of FIG. 5. The processbegins when the next packet arrives at step 510. If the packet isintended for the node at which it is received at step 520, the processis complete and step 510 is repeated. Otherwise, the direction ofrouting required—upstream, downstream, or subscriber-to-subscriber—isdetermined. There are several ways in which the routing direction of apacket can be determined. In some embodiments, each node can haveseparate buffers for upstream, downstream and subscriber-to-subscriberpackets. In other embodiments, the routing process determines thedirection based on the destination. In still other embodiments, thepackets include a flag that indicates the direction. Other techniqueswill be readily apparent to those of skill in the art and are within thepurview of the invention.

If downstream routing is required, subroutine 530 is performed. Ifupstream routing is required, subroutine 540 is performed. Finally, ifsubscriber-to-subscriber routing is required, subroutine 550 isperformed.

The downstream routing subroutine 530 of FIG. 5 is illustrated infurther detail in the flowchart 600 of FIG. 6. A downstream neighbor isselected from the DRT at step 531. If the destination node is adownstream neighbor, the packet is transmitted directly to that node. Ifa destination node is not a downstream neighbor (i.e., is not directlyconnected) but there is only a single path to that node available, thedownstream neighbor node associated with that path is chosen. Otherwise,if multiple paths to the destination node are available, a choicebetween the available paths is made. The choice can be made any numberof ways, including random selection from among the available paths,selection of the first available path found in the routing tables,selection of the least loaded downstream neighbor, etc. As will bediscussed further below, peer routing is also possible.

If the selection of a downstream neighbor at step 531 was successful(i.e., a downstream neighbor was found in the routing tables) at step532, an attempt to transmit the packet to the selected downstreamneighbor is made at step 533. If the packet was successfully transmittedto the selected downstream neighbor at step 534, the downstream routingsubroutine ends and control returns to step 510 of FIG. 5 for processingof the next packet.

If the attempt at step 533 to transmit the packet to the selecteddownstream neighbor was unsuccessful at step 534, then a trigger D1 isgenerated at step 536 and a routing failure procedure is initiated atstep 537. Triggers, including the trigger D1, are messages that triggera routing table update process upon the occurrence of some event.Triggers and the updating of routing tables will be discussed in furtherdetail below. The routing failure procedure of step 637 may be handledin a number of ways. One possibility is that the packet is simplydropped, which will result in the sender failing to receive anacknowledgment from the destination node. Another possibility is to senda failure message to the sending node. This will allow the sending nodeto send another packet as soon as possible (i.e., without waiting for atimeout for an acknowledgment message). This may be desirable fortime-sensitive applications, but there is a performance penaltyassociated with sending such failure messages. Other possibilities willbe apparent to those of skill in the art.

In addition to the trigger D1 of step 536, a second trigger D2 will begenerated at step 538 if no downstream neighbor could be located in theDRT at step 531. The D2 trigger occurs because the upstream neighbor'sDRT indicated that a path to the destination node was available througha node but that node's DRT does not include the destination node. Theprocessing of the D2 and other triggers will be discussed in furtherdetail below.

The upstream routing subroutine 540 of FIG. 5 is illustrated in furtherdetail in the flowchart 700 of FIG. 7. An upstream neighbor is selectedfrom the URT at step 541. If the destination node is the upstreamneighbor, the packet is transmitted directly to that node. If adestination node is not a an upstream neighbor (i.e., is not directlyconnected) but there is only a single path to that node available, theupstream neighbor node associated with that path is chosen. (Note thatthis will be the case where the hop count of the receiving node is 1,because the only upstream neighbor that will be fixed gateway node.)Otherwise, if multiple paths to the destination node are available, achoice between the nodes in the URT (excluding the fixed gateway node,which cannot be directly connected if multiple paths exist) is made. Asdiscussed above in connection with the downstream routing process ofFIG. 6, the choice can be made any number of ways, including randomselection from among the available paths, selection of the firstavailable path found in the routing tables, selection of the leastloaded upstream neighbor, etc. Again, peer routing is also possible.

If the selection of an upstream neighbor at step 541 was successful(i.e., an upstream neighbor was found in the routing tables) at step542, an attempt to transmit the packet to the selected upstream neighboris made at step 543. If the packet was successfully transmitted to theselected upstream neighbor at step 544, the upstream routing subroutineends and control returns to step 510 of FIG. 5 for processing of thenext packet.

If the attempt at step 543 to transmit the packet to the selecteddownstream neighbor was unsuccessful at step 544, then a trigger U1 isgenerated at step 546. Again, the processing of triggers will bediscussed in further detail below. After the U1 trigger is generated atstep 546, or if an upstream neighbor could not be located at step 542, arouting failure procedure is initiated at step 546. Like the downstreamrouting failure procedure, the upstream routing failure procedure ofstep 546 may be handled in a number of ways. One possibility is that thepacket is simply dropped, which will result in the sender failing toreceive an acknowledgment from the destination node. A secondpossibility is to send a failure message to the sending node.

The subscriber-to-subscriber routing subroutine 550 of FIG. 5 functionsby utilizing a combination of the upstream and downstream routingprocedures. When a subscriber node wishes to send a packet to anothersubscriber node that is not in that node's DRT, the packet is sent usingthe upstream routing subroutine 540 described above in connection withthe flowchart 700 of FIG. 7. When the packet reaches the central node,the central node will send the packet downstream using the downstreamrouting subroutine 530 described above in connection with the flowchart600 of FIG. 6.

The routing algorithms discussed above do not use the nodes in the PTsto route packets to peers. Thus, the PTs are only used in the event ofchanges to the routing tables (e.g., through trigger messages as will bediscussed in further detail below). However, as alluded to above, therouting algorithms may be modified to use the PTs. In some embodiments,the PTs are used as alternate upstream routes. In other embodiments, thePTs may be used for downstream routing. In such cases, because peerneighbors do not necessarily include the same subscribers in their DRTs,the construction of the DRTs is modified to include the DRTs of peers aswell. This allows for the use of alternate downstream routes throughpeers whenever available and useful without modification of thedownstream routing process.

Triggers will now be discussed in greater detail. As mentioned above,triggers are messages that are generated upon the occurrence of someevent that trigger the updating of routing tables at the receiving node.The processing of triggers is handled locally by the node receiving thetrigger, and the processing of a trigger may generate another trigger ofthe same type or of a different type. As discussed above, threetriggers—D1, D2 and U1—are generated by the routing algorithms. Theprocessing of these triggers will be discussed in detail.

Trigger D1 occurs when a packet cannot be sent successfully to adownstream neighbor in a node's DRT. The processing of trigger D1 isshown in the flowchart 800 of FIG. 8. Upon receipt of a D1 trigger, thedownstream neighbor N_(k) to which the packet could not be sent is takenout of the downstream neighborhood table at step 810. If the DRT is ofthe type indexed by downstream neighbor, the column of the DRTcorresponding to the unavailable downstream neighbor is updated at step820. (In embodiments in which the DRTs are indexed by destination nodeor are double indexed by destination node and downstream neighbor,appropriate modifications to the network tables are made.) Thedownstream cluster is then computed at step 830 by calculating the unionof the columns of the DRT and adding the node N_(i) and its hop count 0(represented symbolically as {Ni, 0} in FIG. 8) as discussed above.Next, a T4 trigger message including the downstream cluster is sent toupstream neighbors at step 840 (and to peers in embodiments in whichpeer routing is implemented) so that these neighbors can update theirrouting tables. The process is then complete.

Trigger D2 occurs when a packet directed to a destination node isreceived at a node that does not have the destination node in its DRT.The processing of trigger D2 is shown in the flowchart 900 of FIG. 9.Upon receipt of a D2 trigger, the downstream cluster of the receivingnode is calculated at step 910 and a new T4 trigger message includingthe downstream cluster is sent to upstream neighbors at step 920 totrigger the update of the routing tables of the upstream node that sentthe packet. The process is then complete.

Trigger U1 occurs when a packet cannot be sent successfully to anupstream neighbor in a node's URT. The processing of trigger U1 is shownin the flowchart 1000 of FIG. 10. The process begins by removing theupstream neighbor to which the packet could not be sent from the URT forthat node at step 1010. If the URT is not empty at step 1020 (meaningthere is another upstream neighbor through whom packets can be sent),the process ends. If the URT is empty at step 1020, node tables arere-computed at step 1030 as follows: the peer table becomes the upstreamrouting table, and the downstream neighborhood table becomes the peertable. The downstream neighborhood table and downstream routing tablesare then empty. If the URT is still empty at step 1040, the hop countfor that node is set to infinity at step 1050 and processing ends. Ifthe URT is not empty at step 1040, the downstream cluster for the nodeis set to {N_(i)+0} at step 1060 and a T4 trigger message including thedownstream cluster is sent to the upstream neighbors in the URT at step1070 and processing ends.

The T4 trigger is generated during the processing of the routingtriggers as discussed above. The purpose of the T4 trigger is topropagate downstream connectivity changes to upstream nodes in order toupdate their DRTs. The processing of a T4 trigger is illustrated by theflowchart 1100 of FIG. 11. The process begins at step 1110 withincreasing by 1 the hop counts of the nodes in the received Trigger T4and updating the downstream routing table which, in embodiments withDRTs indexed by downstream neighbor, involves replacing thecorresponding column in the DRT with the new column received in the T4trigger message. If the hop count for the node is zero at step 1120(signifying that the highest level node has been reached), the processends as there are no further upstream nodes. If the hop count is notzero at step 1120 (signifying that there is an upstream neighbor), thedownstream cluster is calculated at step 1130 and sent to all upstreamnodes in the URT in a new T4 trigger message at step 1140 and theprocess is complete.

In addition to triggers T1-T4, there is a trigger T5. The T5 trigger isgenerated by a periodic broadcast. That is, each node periodicallybroadcasts its node ID and hop count to inform neighboring nodes of itspresence. When a broadcast message from another node is received thatindicates a change of some kind, the T5 trigger is the mechanism thatpropagates the change through the network.

T5 trigger processing is illustrated by the flowchart 1200 of FIG. 12.Processing begins at step 1201, where the hop count of the nodereceiving the T5 trigger message (HC_(i)) is compared to the hop count(HC_(k)) of the node that sent the T5 trigger message. If the hop countof the receiving node is more than 2 hops downstream of the sendingnode, the processing at step 1210 is performed. If the hop count of thereceiving node is exactly 2 hops downstream of the sending node, theprocessing of step 1220 is performed. If the hop count of the receivingnode is exactly 1 hop downstream of the sending node, the processing ofstep 1230 is performed. If the hop counts are equal, the processing ofstep 1250 is performed. Finally, if the receiving node is upstream ofthe sending node (the hop count of the sending node is greater than orequal to the hop count of the receiving node plus one), the processingof step 1270 is performed.

The processing of step 1210 is illustrated in the flowchart of FIG. 13.The process begins at step 1211, where the DNT, URT and PT of thereceiving node are searched to determine whether the node ID (N_(k)) ofthe sending node is listed in any of those tables as being in theneighborhood of the receiving node. If so, the node is taken out of thecorresponding table at step 1212. Then, or if the sending node was notin any of the neighborhood tables at step 1211, all nodes in the URT andPT for the receiving node are removed from those tables and added to thedownstream neighborhood table DNT and the hop counts in the DNT are setto hop count of the sending node plus 2 at step 1213. The sending nodeis entered in the URT of the receiving node at step 1214, and the hopcount for the receiving nose is set to the hop count of the sending nodeplus 1 at step 1215. Finally, the node ID and hop count of the receivingnode are sent to other nodes in the receiving node's neighborhood in anew T5 trigger message at step 1216 and the process is complete. Inother embodiments, the sending of the new T5 trigger message at step1216 is delayed until the next periodic broadcast. It is also possibleto not update the hop counts at step 1213 but rather update them uponreceipt of a periodic broadcast message from the neighboring nodes,which will contain the updated hop count after the T5 trigger message issent to the neighboring nodes at step 1216.

The processing of step 1220 is illustrated in the flowchart of FIG. 14.The process begins at step 1221, where the DNT, URT and PT of thereceiving node is searched to determine whether the node ID (N.sub.k) ofthe sending node is listed in any of those tables as being in theneighborhood of the receiving node. If so, the node is taken out of thecorresponding table at step 1222. Next, the PT, DNT and URT are updatedat step 1223. The nodes previously listed in the peer table PT are addedto the downstream neighbor table DNT, the nodes previously listed in theURT are moved to the PT, and the hop counts are appropriately modified.The sending node is entered in the URT of the receiving node at step1224, and the hop count for the receiving nose is set to the hop countof the sending node plus 1 at step 1225. Finally, the node ID and hopcount of the receiving node are sent to other nodes in the receivingnode's neighborhood in a new T5 trigger message at step 1226 and theprocess is complete. The alternative embodiments and methods discussedabove in connection with FIG. 13 are applicable to the processing ofFIG. 14 as well.

The processing of step 1230 (the hop count of the receiving node is onegreater than the hop count of the sending node) is illustrated in theflowchart of FIG. 15. If the sending node is listed in the URT of thereceiving node at step 1231, then processing is complete as there hasbeen no change in the relative position of the sending and receivingnodes. If the sending node is not in the URT of the receiving node, thenthe DNT and PT of the receiving node are checked at step 1232 todetermine if the sending node is listed in either of those tables. Ifso, the sending node is taken out of the corresponding table at step1233. Next, or if the sending node was not in any of the neighborhoodtables at step 1232, the sending node is added to the URT of thereceiving node at step 1234 as the sending node has a lower hop countthan the receiving node. The downstream cluster of the receiving node iscomputed at step 1235. Next, a check is made at step 1236 to determineif the sending node was previously listed in the downstream neighborhoodtable of the receiving node. If so, a T4 trigger message including thedownstream cluster is sent to the sending node at step 1237 andprocessing is complete. If the sending node was not previously listed inthe receiving node's downstream neighborhood table at step 1236, the T4trigger message with the downstream cluster calculated at step 1235 issent to the nodes in the receiving node's upstream routing table at step1238 and processing is complete.

The processing of step 1250 is illustrated in the flowchart of FIG. 16.If the sending node (whose hop count is equal to the receiving node'shop count) is already listed in the peer table of the receiving node atstep 1251, then processing is complete as there has been no change inthe relative position of the sending and receiving nodes and nothingmore need be done. If the sending node is not in the PT of the receivingnode at step 1251, then the DNT and URT of the receiving node arechecked at step 1252 to determine if the sending node is listed ineither of those tables. If so, the sending node is taken out of thecorresponding table at step 1253. Next, or if the sending node was notin the peer table at step 1252, the sending node is added to the PT ofthe receiving node at step 1254. Next, if the URT is not empty at step1255, processing is complete.

If the URT is empty at step 1255 (meaning that there is no upstream nodeand hence no way to reach the fixed gateway node), then the threeneighborhood tables are re-computed at step 1256. First, the nodeslisted in the PT are moved to the URT (i.e., since no upstream node isavailable, packets destined for the fixed gateway node will be routedthrough a peer). Then, nodes listed in the downstream neighborhood tableare moved to the peer table, and the downstream neighborhood table anddownstream routing table are left empty. If the URT is still empty atstep 1257 (i.e., there were no peers in the PT), then no path to thefixed gateway node is available and the hop count for the receiving nodeis set to infinity at step 1258 and processing is complete. If, however,the URT was not empty at step 1257, the downstream cluster is calculatedat step 1259 and sent to the upstream neighbors at step 1260 andprocessing is complete.

The T5 trigger discussed above will generally propagate downstreambecause it is initiated by a new RF association with a fixed gatewaynode. This downstream propagation will work even when nodes are isolated(i.e., have an infinite hop count) because the comparison between aninfinite hop count with a finite hop count will select the processing ofstep 1210.

The processing of step 1270 (the hop count of the sending node is atleast one greater than the hop count of the receiving node) isillustrated in the flowchart of FIG. 17. If the sending node is alreadylisted in the downstream neighbor table of the receiving node at step1271, then the hop count of the sending node is set equal to the hopcount of the receiving node plus one at step 1272 and a new T5 triggermessage including the hop count of the receiving node is sent to thesending node at step 1273 and processing is complete. If the sendingnode is not in the DNT of the receiving node at step 1271, then the PTand URT of the receiving node are checked at step 1274 to determine ifthe sending node is listed in either of those tables. If so, the sendingnode is taken out of the corresponding table at step 1275. Next, or ifthe sending node was not in the peer table or URT at step 1274, thesending node is added to the downstream neighbor table of the receivingnode at step 1276. The hop count of the sending node is set equal to thehop count of the receiving node plus one at step 1277. Next, if the URTis not empty at step 1278, the node identification and hop count of thereceiving node are sent to the sending node at step 1273 and processingis complete. It should be noted that, in alternative embodiments, it isalso possible to wait for the next periodic broadcast from neighboringnodes to update the hop counts rather than updating the hop counts atstep 1256.

If the URT is empty at step 1278 (meaning that there is no upstream nodeand hence no way to reach the fixed gateway node), then the threeneighborhood tables are re-computed at step 1279. First, the nodeslisted in the PT are moved to the URT (i.e., since no upstream node isavailable, packets destined for the fixed gateway node will be routedthrough a peer). Then, nodes listed in the downstream neighborhood tableare moved to the peer table, and the downstream neighborhood table anddownstream network table are left empty. If the URT is still empty atstep 1280 (i.e., there were no peers in the PT), then no path to thefixed gateway node is available and the hop count for the receiving nodeis set to infinity at step 1281 and step 1273 is performed. If, however,the URT was not empty at step 1280, the downstream cluster is calculatedat step 1282 and sent to the upstream neighbors in a T4 trigger messageat step 1283. Then, the node identification and hop count of thereceiving node are sent to the sending node at step 1273 and processingis complete. It should be noted that the alternatives discussed above inconnection with FIG. 13 (i.e., not updating the hop counts at step 1279and waiting until the next periodic broadcast to send the hop counts andnode IDs rather than sending them at step 1273) are also applicable tothis processing.

In addition to the triggers described above, a mechanism to removeobsolete links from the upstream routing table, peer table anddownstream network table is necessary. This mechanism can take the formof periodic audits in which all of the nodes in the aforementionedtables are checked periodically. Alternatively, an activity watchdog foreach neighbor node can be set up to trigger action if the neighbor nodehas been idle for too long.

The first mechanism involves periodically auditing the entries for theURT, PT and DNT. In the URT audit, the time since each node in the URThas been heard from is checked. If a node has been silent for more thana threshold period of time, the node is removed from the URT and theprocessing associated with a T3 trigger (steps 1010-1070 of FIG. 10) isperformed. If a peer node in the PT has been inactive for more than athreshold period of time, it is simply removed from the peer table.Finally, in the DRT audit, the time since each node in the DRT has beenheard from is checked. If a downstream node in the DRT has been inactivefor more than a threshold period of time, the processing associated witha T1 trigger (steps 810-840 of FIG. 8) is performed.

The processing of the second mechanism, activity watchdogs, works in thesame fashion described above in connection with the periodic auditswhenever an activity watchdog indicates that a node has been idle formore than a threshold period of time.

Any given mobile node will be associated with a growing number of fixedgateway nodes over time as that mobile node moves around. As a practicalmatter, preferred embodiments maintain only a limited number ofassociations (e.g., 3) with fixed gateway nodes. In such embodiments,the maintained associations are referred to as principal associations.One way that this can be accomplished is by having a new associationreplace an old association and trigger its elimination in theneighborhood tables. If a principal association with a fixed gatewaynode becomes “broken” (i.e., communications with the fixed gateway nodebecome impossible), the association becomes inactive but is stillmaintained (i.e., it is not dropped as in the case where a newassociation replaces an old one) as a peer node. It is important tocontinue maintaining inactive associations because they may becomeactive again (e.g., a mobile unit makes a U-turn or goes around a curvein the road).

In the embodiments described above, a correction in a DRT is immediatelypropagated upward. Since URT corrections propagate downward, this willcreate successive waves of DRT update propagation upward as the URTcorrections propagate downward. In this manner, infrastructure updatesare propagated immediately, which results in fewer mishandled packets.However, this requires more CPU resources. Alternatively, the algorithmsdiscussed herein can be modified so that any upstream propagation of DRTupdates only occurs when a node that has modified its DRT has nodownstream neighbors. This would delay infrastructure updates, but wouldbe computationally more economical.

Obviously, numerous other modifications and variations of the presentinvention are possible in light of the above teachings. It is thereforeto be understood that within the scope of the appended claims, theinvention may be practiced otherwise than as specifically describedherein.

1. A network comprising: at least one fixed gateway node, the fixedgateway node being in communication with the Internet; and a pluralityof wireless nodes, each of the wireless nodes including wirelesstransceivers, each of the wireless nodes includes an upstream routingtable and a downstream routing table, each of the wireless nodes beingconfigured to use its upstream and downstream routing tables to makerouting decisions, some of the wireless nodes being mobile wirelessnodes, some of the mobile wireless nodes being configured to act as arelay for other wireless nodes that cannot directly access the at leastone fixed gateway node; wherein at least one first wireless node has anupstream routing table listing a second node and a corresponding hopcount relative to the at least one fixed gateway node for the secondnode, the corresponding hop count for the second node being lower than ahop count for the first wireless node, and wherein at least one thirdwireless node has a downstream routing table listing at least one fourthwireless node with a corresponding hop count relative to the at leastone fixed gateway node, the corresponding hop count for the fourthwireless node being higher than the hop count for the third wirelessnode.
 2. The network of claim 1, wherein the at least one fixed gatewaynode is directly connected to the Internet.
 3. The network of claim 1,wherein the at least one fixed gateway node includes a plurality offixed gateway nodes.
 4. The network of claim 1, wherein the at least onefixed gateway node is connected to the Internet via a central node. 5.The network of claim 4, wherein the central node is connected to atleast one other fixed gateway node.
 6. The network of claim 1, whereineach of the wireless nodes is configured to act as a relay for otherwireless nodes that cannot directly access the at least one fixedgateway node.
 7. The network of claim 1, wherein each wireless nodefurther comprises a peer table that lists all directly accessible nodeshaving a same hop count to the at least one fixed gateway node as thewireless node.
 8. The network of claim 1, wherein all of the wirelessnodes are mobile nodes.
 9. The network of claim 1, wherein some of thewireless nodes are mobile nodes and other wireless nodes are fixednodes.
 10. The network of claim 1, wherein the downstream routing tablesare indexed by destination node.
 11. The network of claim 1, wherein thedownstream routing tables are indexed by downstream neighbor.
 12. Thenetwork of claim 1, wherein the downstream routing tables are indexed byboth destination node and downstream neighbor.
 13. A method for routinga packet received performed by a first wireless node in an ad-hocnetwork that includes at least one fixed gateway node comprising thesteps of: selecting a node to which to transmit the packet from anupstream routing table if the direction of the packet is upstream, theupstream routing table including a list of all directly accessible nodeshaving a hop count less than the first wireless node relative to thefixed gateway node; selecting a downstream node to which to transmit thepacket from a downstream routing table if the direction of the packet isdownstream, the downstream routing table including a list of alldirectly connected nodes and all downstream nodes having at least oneshortest path that passes through the wireless node; and transmittingthe packet to the selected downstream node.
 14. The method of claim 13,further comprising the step of receiving the packet from anotherwireless node prior to performing either of the selecting steps.
 15. Themethod of claim 14, wherein the packet is received in either an upstreambuffer or a downstream buffer, and either upstream routing or downstreamrouting are performed depending on whether the packet is received in theupstream buffer or the downstream buffer.
 16. The method of claim 13, inwhich the packet includes a flag indicating whether the packet is to berouted upstream or downstream.
 17. The method of claim 13, furtherincluding the step of determining a direction of the packet based on adestination included in the packet.
 18. The method of claim 14, furthercomprising the steps of transmitting a trigger message including thedownstream cluster if a destination node associated with the packet isnot listed in the downstream routing table.
 19. The method of claim 13,further comprising the steps of updating the downstream routing table byremoving the selected node if the packet could not be transmitted to theselected node, calculating the downstream cluster based on the updatedrouting table, and transmitting a trigger message including thedownstream cluster to nodes listed in the upstream routing table. 20.The method of claim 13, further comprising the steps of removing theselected node from the upstream routing table if the direction of thepacket is upstream and the packet could not be transmitted to theselected node.